Unstub validator rpc #188
Unstub validator rpc #188
Conversation
|
Why did you re-implement all the functions? If anything you could import them from the beacon chain since its in the same project. Also - check out my pr #185 because the RPC methods you'll need are a lot lighter |
TBH I failed to find some of this methods in chain folder, my bad (was late when I was searching) :( Do you plan exposing get_committee_assignment as validator rpc or should we calculate it in validator code? Depending on that I will either change to import from chain directory or make a call to API. |
Ahhh dont worry
Well I think the validator wouldn't need that because the assingment would be passed in via the |
My chain of thought was to offload some of the computing from beacon node as all these stuff can be calculated from BeaconState. |
Hmm.... I see what you're saying, I guess it matters on how "stateless" we want to be. Also bare in mind that #185 is loosely implemented off of ethereum/consensus-specs#1011 |
|
How about this interface for validator client? |
|
Yeah lets take a back seat on this, I'm changing the api again |
|
This is probably good to finish |
I started unstubbing validator rpc calls.
I'm not really sure how much of that will end up in beacon/validator api in beacon node so I've put abstract class that implements all those data processing functions that validator require.
I would leave them for now like this until rpc endpoints are defined and then we can either move this logic from
AbstractClientto beacon node. If they are going to stay in validator it should probably be extracted to some class with more sane name.I would like if you could check if I implemented those things correctly before I start writing tests.